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REMARKS 

Claims 1-4 and 6-32 are pending in this application. Claims 18 and 26-28 are 
amended. 

Applicant would like to thank the Examiner for the courtesy extended during the 
telephonic interview on February 19, 2008. During the interview, the Examiner and 
applicant's representative discussed the claim rejections under 35 U.S.C. § 101. Applicant 
would like to thank the Examiner for his helpful suggestions as to how the section 101 
rejections might be overcome. 

The Examiner has rejected claims 18 and 26-28 under 35 U.S.C. § 101; rejected 
claims 1-4, 6-8, 10-14, 16-22, 24-27, 29, and 32 under 35 U.S.C. § 103(a) over Bunney 
and Runyan; rejected claims 9, 15, 23, and 28 under 35 U.S.C. § 103(a) over Bunney, 
Runyan, Aravamudan, and Munday; rejected claim 30 under 35 U.S.C. § 103(a) over 
Bunney, Runyan, and IVIunday; and rejected claim 31 under 35 U.S.C. § 103(a) over 
Bunney, Runyan, and Aravamudan. 

Rejections Under 35 U.S.C. § 101 

The Examiner has rejected claims 18 and 26-28 under 35 U.S.C. § 101. Without 
conceding the propriety of this rejection, applicant has elected to amend the claims to 
address the Examiner's concerns. In particular, claims 18 and 26-27 have been amended 
to recite "a computer-readable storage medium." In addition, claims 27-28 have been 
amended to recite "a computer program product stored on a computer-readable storage 
medium ." As such, the claims are directed to tangible computer storage media and are not 
intended to encompass non-statutory subject matter. Accordingly, applicant respectfully 
requests that the section 101 rejections be withdrawn. 
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Rejections Under 35 U.S.C. S 103(a) 

A. The Examiner's Rejections 

1. The Examiner rejected claims 1-4, 6-8, 10-14, 16-22, 24-27, 29, and 
32 under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,487,584 to 
Bunney and "All quiet on the NetWare front" by Runyan. 

2. The Examiner rejected claims 9, 15, 23, and 28 under 35 U.S.C. 
§ 103(a) as being unpatentable over Bunney, Runyan, U.S. Patent No. 6,301,609 to 
Aravamudan, and U.S. Patent No. 6,480,593 to Munday. 

3. The Examiner rejected claim 30 under 35 U.S.C. § 103(a) as being 
unpatentable over Bunney, Runyan, and Munday. 

4. The Examiner rejected claim 31 under 35 U.S.C. § 103(a) as being 
unpatentable over Bunney, Runyan, and Aravamudan. 

B. Issues 

1 . Whether Bunney suggests determining a master status in accordance 
with a status update and each client view status. The decision on this issue impacts all of 
the claims. 

2. Whether one would be motivated to combine Runyan's suggestion 
that a user may be logged on to several clients with Bunney's solution to a problem that 
occurs when a user is logged on to only one address. The decision on this issue impacts 
all of the claims. 

3. Whether Bunney suggests reflecting the master status of the user to 
other electronic messaging users. The decision on this issue impacts claims 1-4, 6-9, 16, 
and 19-28. 
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4. Whether the combination of Bunney, Runyan, and Aravamudan 
suggests changing the master status according to a detailed priority system. The decision 
on this issue impacts claims 9, 15, 23, and 28. 

5. Whether Munday suggests when one client indicates that the user is 
busy and another client indicates that the user is idle, setting the master status to indicate 
that the user is busy. The decision on this issue impacts claim 30. 

6. Whether Aravamudan suggests when all but one client indicates that 
the client is offline, setting the master status to the status of the client that is currently 
online. The decision on this issue impacts claim 31 . 

C. Overview of the Invention and Prior Art 
1. The Invention 

Applicant's invention is directed to a technology that facilitates maintaining accurate 
presence information for a user who is logged on with two or more clients, such as in an 
instant messaging environment. {See, e.g., Specification, 8:8-12.) Instant messaging is a 
form of electronic communication that allows real time electronic communications among 
users. The ability to communicate in real time is one of the primary differences between 
instant messaging and other forms of electronic communication, such as email. {See, e.g., 
id., 2:12-20.) Notifying other instant messaging users of a particular user's status (e.g., 
available, away, busy) is an essential component of instant messaging. For example, if a 
first user is notified that a second user is away from his computer, the first user may decide 
not to compose and send an instant message to the second user because the second user 
will not receive the message in real time. {See, e.g., id., 3:5-18.) A user's status may be 
referred to as "presence information," and may be provided to other users as indicative of 
the user's availability. {See, e.g., id., 2:24-3:4.) 

Providing other users with accurate presence information for a particular user may 
become difficult when the user is associated with or logged on to more than one client. 
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{See, e.g., id., 4:3-9.) For example, a user may log on to the instant messaging 
environment with an identity (e.g., user@xxx.com) using a desktop computer and again 
with the same identity using a personal digital assistant. Each client may indicate a 
different status for the user. For example, the user may be idle on the desktop computer 
but busy on the personal digital assistant. Providing accurate presence information was 
not a problem with prior techniques because the prior techniques required that a user be 
logged on to only one device at a time. Applicant's technology allows a user to be logged 
on to two or more devices at the same time. 

Applicant's technology evaluates the user's status on each of the two or more 
clients, including any status update (e.g., a change in status from away to busy), to 
determine an accurate master, or overall, status for the user. {See, e.g., id, 5:24-6:5.) For 
example, the user who is idle on a desktop computer but busy on a personal digital 
assistant may have an overall status of busy, because even though the user is idle at one 
client, the user is busy at another. To determine the master status, applicant's technology 
first creates and maintains a client view status for each client. Each client view status 
correlates to the status of the client, e.g., online, offline, away, invisible, busy, etc. {See, 
e.g., id., 5:17-22.) Applicant's technology determines the master status of the user by 
evaluating each of the client view statuses and any status update. {See, e.g., id., 5:24- 
6:2.) In some embodiments, applicant's technology determines the master status 
according to specified priority rules. For example, if the status of one client changes to 
offline, applicant's technology will not update the master status to offline unless the user is 
offline on all other clients. This allows a user who is, for example, busy on one client but 
offline on another to still be accurately reflected as busy. {See, e.g., id., 19:10-20:13.) 
Once the master status has been determined, applicant's technology may provide the 
master status to the user and to other users for use in determining how best to 
communicate with the user. {See, e.g., id., 6:3-5.) 
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2. The Bunnev Reference 

Bunney discloses a solution to a problem that may occur when a user is logged in 
with one of several addresses, and the other addresses assigned to the user are not in a 
logged in state. In such a situation, the user may not receive messages addressed to any 
of the user's non-logged in addresses. (Bunney, 1 :24-30.) For example, a user may have 
the identities of "George@compu.xxx.com" and "Superman@sport.xxx.com." Bunney 
describes that under the prior art, if a user was logged in with the address 
"George@compu.xxx.com" and a message was sent to "Superman@sport.xxx.com," the 
user would not be notified of the message until the next time the user logged in with the 
address "Superman@sport.xxx.com." 

Bunney's solution is to notify a user who is logged in with the first of several 
addresses of a message received at a second, non-logged in address. {Id., 1:45-48.) 
Under the above example, if a user was logged in with the address 
"George@compu.xxx.com" and a message was sent to "Superman@sport.xxx.com," the 
user may be notified of the message through the user's "George@compu.xxx.com" 
identity. The user could then log out of the "George@compu.xxx.com" identity and log in 
using the identity of "Superman@sport.xxx.com" to review the message. To provide this 
notification, Bunney describes a server that maintains a table associating a user with each 
of several addresses assigned to the user. {Id., 1:56-59.) When a message is sent to one 
of the user's non-logged in addresses, the server consults the table of assignments to 
identify the assigned addresses and then checks whether the user is currently logged in to 
one of those addresses. If so, the server may send a notification to the user's logged in 
address that the user has received a message at one of the user's non-logged in 
addresses. (W., 1:60-67.) 

Under Bunney, when a user is logged in, the user may have one of four statuses: 
available, invisible, away, and busy. {Id., 7:5-30.) A status of invisible prevents a user 
from being visible to other users' searches and from receiving other users' notifications. 
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According to Bunney, if a user is invisible, other users will not know anything about the 
user, including that the user is online. 

In addition to, but distinctive from, the statuses described above, Bunney allows a 
user who is logged in through one address to associate a do not disturb sign with one or 
more of the user's other addresses. For example, a user logged in with the address 
"George@compu.xxx.com" can place a do not disturb sign that indicates he does not want 
to receive any message or notification addressed to his other address 
"Superman@sport.xxx.com." {Id, 9:25-35.) Bunney's Session Manager monitors whether 
a user has placed a do not disturb sign and communicates with the Notification Server, 
which uses the information to determine whether to send notifications to the user. {Id, 
4:38-47.) 

3. The Runvan Reference 

Runyan describes improving security on NetWare networks. Runyan describes that 
one user can log in to a network from more than one workstation at the same time. As a 
security measure, Runyan suggests limiting the number of workstations from which one 
user may log in at the same time, using the same user identification. 

4. The Aravamudan Reference 

Aravamudan describes a messaging solution that features a user-selected priority 
system. A user may create groups of buddies (e.g., other users) and define specific 
attributes that are associated with the buddies in each group. (Aravamudan, 2:33-35.) 
One of the attributes to be defined by the user is a user-selected priority system. In the 
exemplary embodiment described, the user may assign one of three priorities to each 
group of buddies: low, high, or highest. These priorities determine whether another user 
has access to the user's presence information and how the users will interact with each 
other. For example, buddies who are assigned a low priority will never be able to see 
whether a user is online or offline, and will always communicate with the user via a user 
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proxy. Buddies who are assigned a high priority will be able to see the user's online status 
anytime the user is online. Buddies who are assigned the highest priority can interface 
with the user directly when the user is online and via user proxy when the user is offline. 
{Id, 2:35-49.) 

5. The Mundav Reference 

Munday describes a communications system for automatically diverting calls from a 
local telephone to a remote telephone when a user is not in the vicinity of the local 
telephone. For example, a local telephone may be located in a user's office or other 
working area, in proximity to a user's computer system. When a user has not interacted 
with his computer system for a predetermined period of time, the computer system infers 
that the user is absent from his working area and diverts calls from the local telephone to 
the remote telephone. (Munday, abstract; 1:27-35; 2:37-44.) 

D. Obviousness Rejections 

1. Legal Standards for Obviousness 
All of the claims stand rejected under 35 U.S.C. § 103(a), which provides: 

A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between 
the subject matter sought to be patented and the prior art are such that the 
subject matter as a whole would have been obvious at the time the invention 
was made to a person having ordinary skill in the art to which said subject 
matter pertains. Patentability shall not be negatived by the manner in which 
the invention was made. 

To properly reject claims as obvious, "the examiner bears the initial burden of presenting a 
prima facie case of obviousness." In re Rijckaert, 9 F.3d 1531, 1532, 28 U.S.P.Q.2d 
(BNA) 1955, 1956 (Fed. Cir. 1993). To present a prima facie case of obviousness, the 
Examiner must show that "there was an apparent reason to combine the known elements 
in the fashion claimed by the patent at issue." KSR Int'l Co. v. Teleflex Inc., No. 04-1350, 
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slip op. at 14 (U.S. Apr. 30, 2007). Relevant considerations may include "interrelated 
teachings of multiple patents; the effects of demands known to the design community or 
present in the marketplace; and the background knowledge possessed by a person having 
ordinary skill in the art." Id. The Examiner's analysis "should be made explicit." Id. 
"[R]ejections on obviousness grounds cannot be sustained by mere conclusory 
statements; instead, there must be some articulated reasoning with some rational 
underpinning to support the legal standard of obviousness." Id. (citing In re Kahn, 441 
F.3d 977, 988 (Fed. Cir. 2006)). 

Under these standards, applicant's invention would not have been obvious. The 
Examiner has not identified references that disclose or suggest all the elements of the 
pending claims. Furthermore, the combination of references cited by the Examiner would 
not operate in the manner the Examiner suggests. Therefore, applicant respectfully 
requests that the rejections under 35 U.S.C. § 103(a) be withdrawn. 

2. Discussion of Issues 

In rejecting the pending claims, the Examiner has mapped the elements of the prior 
art to applicant's claim elements in inconsistent and contradictory ways. For example, the 
Examiner argues that Bunney's address with which the user is logged in corresponds to 
applicant's "master status." (Office Action, Dec. 13, 2007, p. 4.) However, the Examiner 
also argues that Bunney's providing a user's status (e.g., available, away, or busy) to other 
users corresponds to applicant's "reflecting" the master status. (Id.) It is contradictory for 
the Examiner to take the position that Bunney's address corresponds to applicant's master 
status and then to take the position that Bunney's user status corresponds to applicant's 
master status. As another example, applicant's master status is determined by evaluating 
"a first status update, a first view status, and a second view status." The Examiner, 
however, points to Bunney's address as corresponding to applicant's "first view status." 
{Id., p. 3.) Thus, the Examiner argues that Bunney's address corresponds to both 
applicant's master status and first view status. Because applicant's master status is 
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determined by evaluating the first view status in addition to other factors, as stated above, 
the Examiner's suggestion that applicant's master status is the same as applicant's first 
view status is inconsistent. Because of the inconsistent positions taken by the Examiner, it 
is difficult for applicant to respond to the Examiner's arguments in as straightforward a 
manner as applicant would like. Applicant has attempted to respond to each of the 
Examiner's contradictory arguments. 

a. Bunnev fails to teach or suggest determining a master 
status in accordance with an evaluation of a status 
update and each client view status. 

All of the claims recite determining a master status in accordance with an evaluation 
of a status update and each client view status. For example, claim 1 recites: 

in response to receiving the first status update, the server evaluating at least 
the first status update, the first view status, and the second view status 
according to specified status rules to determine the master status of the 
electronic messaging user ... 

In other words, the server receives a status update when one of the user's client computer 
systems detects a change in the status of the electronic messaging user, e.g., a change 
from away to busy. (Specification, 14:1-2.) The server evaluates the status update and 
the statuses of all other client computer systems, which are obtained from each client view 
status maintained by the server. The server uses specified rules to reconcile differing 
statuses and determine the master status. 

Bunney does not describe any element that corresponds to applicant's "master 
status." Applicant's master status of an electronic messaging user is determined by 
"evaluating at least the first status update, the first view status, and the second view 
status," as described above. The Examiner points to Bunney at 9:1-20 as disclosing a 
master status, explaining that "Bunney discloses the server checking a table to see which 
address to send a notification to." (Office Action, Dec. 13, 2007, p. 4.) It is apparently the 
Examiner's position that Bunney's "address to send a notification to" (i.e., the address with 
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wliich a user lias logged in) corresponds to applicant's "master status." However, these 
concepts are distinct. Applicant's master status is not an address; rather, it is an overall 
status (e.g., online, offline, away, busy, invisible) that is formed by evaluating the status 
update and the client view statuses according to specified rules. In contrast, the address 
through which the user has logged on in Bunney is not determined by evaluating a status 
update or client view statuses, nor is it determined according to specified status rules. 

Further, the Examiner believes that Bunney's logged on address corresponds to 
applicant's "first view status," in addition to corresponding to applicant's master status, as 
described above. When discussing applicant's claim language "maintaining at the server a 
first view status," the Examiner states that "Bunney discloses an address a user has 
logged in with on a certain terminal." {Id, p. 3.) Applicant's first view status and master 
status are two different statuses. The master status is determined by "evaluating at least 
the first status update, the first view status, and the second view status." Clearly, 
applicant's first view status and master status are distinct. The Examiner has pointed to a 
single address as corresponding to both statuses, without explaining how a single address 
can correspond to both statuses. 

Even if Bunney disclosed a master status, Bunney does not disclose determining a 
master status in accordance with an evaluation of a status change and each client view 
status. Bunney's Session Manager does maintain infomriation about the status of a user, 
which may include available, away, invisible, or busy. (Bunney, 7:5-9.) Except when a 
user's status is invisible, the status is displayed to other network users. However, even if 
Bunney allowed a user to be logged in to two or more clients at the same time, Bunney 
offers no teaching that it would attempt to evaluate a status change and each client view 
status to determine a master status. Bunney offers no guidance to remedy a situation, for 
example, where a user is "busy" on one client and "available" on another. 
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The Examiner does not rely on Runyan for curing this deficiency of Bunney. 
Indeed, Runyan cannot cure this deficiency, as it neither teaches nor suggests determining 
a master status for a user. 

b. The Examiner's suggestion to modify Bunnev with 
Runvan's suggestion that a user mav be logged on to 
several clients would obviate the need for Bunnev's 
solution, which the Examiner relies upon in rejecting the 
claims. 

All of the claims recite that an electronic messaging user is logged on to at least two 
clients at the same time. For example, claim 1 recites: 

the electronic messaging user ... who is logged on via both the first client 
computer system and the second client computer system as an electronic 
messaging user. 

For example, a user may be logged on to an instant messaging environment through both 
a desktop computer and a personal digital assistant. Applicant's claims are directed to 
maintaining a master status for the user even though the status of the user (e.g., online, 
offline, away, busy) may differ on the desktop computer and the personal digital assistant. 

The Examiner acknowledges that Bunney fails to teach the limitation of an 
electronic messaging user logged on to at least two clients at the same time. The 
Examiner points to Runyan to cure this deficiency. (Office Action, Dec. 13, 2007, p. 5.) 
Runyan describes that a user may be logged in to a NetWare network, or a network 
operating system, from one or more different workstations. It would, however, be 
contradictory to combine Bunney's technique that solves a problem that occurs when a 
user is logged in on one address with Runyan's technique that allows a user to log in at 
several workstations. Bunney is designed to address a problem that occurs when a user 
has several addresses, the user is logged in to a network under only one address, and a 
message is sent to another of the user's addresses. Bunney describes the problem it 
intends to solve as follows: 
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when the user has logged in with one of said several addresses, and the 
other addresses assigned to the same user are not in a loaaed-in state , no 
message or notification from a server or another user terminal can be 
fonwarded to the user, when the notification or message is addressed to one 
of the addresses which are in a non-logged-in state. 

(Bunney, 1:24-30, emphasis added.) In explaining its solution to this problem, Bunney 
describes a user logged in to a network with one of the user's several addresses. A server 
or another user sends a message to a second of the user's addresses, i.e., one of the 
user's addresses that is in a non-logged in state. The server consults its table of 
assignment information to determine whether the user associated with the second address 
is logged in to the network through another address. If so, the server will notify the user 
through the user's logged in address that a message has been sent to the user's second, 
non-logged in address. {Id., 1:60-67.) Further, Bunney emphasizes that its' Session 
Manager "allows a user to log into the system once ..." {Id., 4:35-36, emphasis added.) 

It is the Examiner's position that one would be motivated to combine Bunney and 
Runyan to have an electronic messaging user logged on to at least two clients at the same 
time "because it allows the user to be logged onto multiple devices and it allows other 
users to find them based on their state." (Office Action, Dec. 13, 2007, p. 5.) Combining 
Bunney and Runyan to allow a user to be logged on to multiple devices using different 
addresses would, however, entirely avoid the problem Bunney attempts to solve. If a user 
were logged on to a device for each of his different addresses, and a message were sent 
to any of the user's addresses, the user would receive the message. There would be no 
need for Bunney's solution, i.e., providing notification to the user that a message has been 
received at one of the user's addresses that is not in a logged on state. The Examiner's 
suggestion is thus not a suggestion to modify Bunney, but rather a suggestion to entirely 
avoid the problem Bunney attempts to solve by requiring the user to log on through 
multiple addresses. 

Furthermore, the Examiner's rejection relies upon both Bunney's solution and 
Runyan's multiple log on in rejecting the claims. For example, the Examiner relies upon 
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Bunney's solution of "checking the table to see which address to send a notification to." 
{Id, p. 4.) Such checking of a table would not be needed, however, if Bunney was 
modified to allow a user to log on to multiple addresses as suggested by Runyan. Thus, 
the Examiner is applying the suggested combination in contradictory ways. 

c. Bunnev fails to teach or suggest reflecting the master 
status of the user to other electronic messaging users. 

Many of the claims recite reflecting the master status of the user to other electronic 
messaging users. For example, claim 1 recites: 

reflecting an indication of the master status for the electronic messaging user 
identified by the user identification to other electronic messaging users. 

One of the benefits of an electronic messaging environment is that a user's status is 
reflected, e.g., displayed, to other users. When the user is logged on through two or more 
clients, applicant's technology reflects a user's master status to other users in the 
environment, rather than reflecting the status information of the client or clients separately. 

Even if Bunney were to create a master status, it does not disclose reflecting such a 
status to other users. The portions of Bunney cited by the Examiner do not teach or 
suggest reflecting the master status of the user to other electronic messaging users. 
(Bunney, 7:5-30; 9:25-35.) The first cited portion of Bunney describes that the Session 
Manager maintains information about the user's status, which may be available, away, 
invisible, or busy. {Id., 7:5-30.) This status information is provided to other users. 
However, the information maintained by Bunney's Session Manager and reflected to other 
users is simply the status of one of the user's clients; it is not a master status, determined 
by evaluating the status of each of the user's two or more clients. 

In addition, the Examiner previously indicated that applicant's master status was 
equivalent to Bunney's logged in address, as described above. It is inconsistent for the 
Examiner to now indicate that the master status reflected to other users is in the form of 
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status information (e.g., available, away, or busy). Further, even if applicant's master 
status were equivalent to Bunney's logged in address, Bunney's logged in address is never 
reflected to other users. Accordingly, Bunney fails to teach or suggest reflecting the 
logged in address of the user, which the Examiner believes corresponds to applicant's 
master status, to other electronic messaging users. 

The second portion of Bunney cited by the Examiner describes a "do not disturb 
sign" that may be used by the user. (Bunney, 9:25-35.) A user logged in through one 
address may associate a do not disturb sign with one or more of the user's other 
addresses. For example, a user logged in with the address "George@compu.xxx.com" 
can place a do not disturb sign that indicates that the user does not want to receive any 
message or notification addressed to the user's other address 
"Superman@sport.xxx.com." A do not disturb sign is not status information (e.g., 
available, away, or busy); instead, it is a separate signal used to communicate with the 
server. The presence of a do not disturb sign is monitored by the Session Manager and is 
communicated to the Notification Server, which uses the information to determine whether 
to send notifications to the user. {Id, 4:38-47.) The do not disturb sign is not reflected to 
other users; other users only have access to the status of the user, such as available, 
away, or busy. Further, the do not disturb sign is not equivalent to applicant's master 
status. Even if Bunney were to permit an electronic messaging user to be logged on to two 
or more clients at the same time, Bunney offers no teaching about how a do not disturb 
sign on one of the user's clients (i.e., non-status information) would be reconciled with 
status information presented by another of the user's clients. Indeed, it would be 
incongruous to attempt to reconcile these two diverse concepts. 

The Examiner does not rely on Runyan for curing this deficiency of Bunney. 
Indeed, Runyan cannot cure this deficiency, as it neither teaches nor suggests reflecting a 
master status for a user to other electronic messaging users. 
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d. Bunnev, Runvan. and Aravamudan fail to teacli or 
suggest updating the master status according to a 
detailed priority system. 

Seyeral of the claims recite updating the master status according to a detailed 
priority system. For example, claim 15 recites: 

... changing the presence information according to a priority system further 
comprises at least one of: 

changing the presence information to offline if the status update 
indicates the electronic messaging user is invisible; 

changing the presence information to offline if the status update 
indicates the electronic messaging user is offline and the remaining 
view statuses indicate the electronic messaging user is offline; 

changing the presence information to idle if the status update 
[indicates] the electronic messaging user is idle and the remaining 
view statuses indicate the electronic messaging user is idle or offline; 
and 

changing the presence information to match the status update. 

Each of these rules for changing the master status is a specific example of updating 
the master status by evaluating "a first status update, a first view status, and a second 
view status." For example, the first rule applies where the first status update, and thus the 
first view status, is invisible; the second view status may be any status. When the first 
status update is invisible, it indicates that the user does not want to be seen by other 
users. Thus, according to the first rule, the master status will be changed to offline. 

It is the Examiner's position that Bunney discloses the first of these priority rules. 
The Examiner points to Bunney at 7:10-15 as disclosing this priority rule, explaining that 
"Bunney discloses the use of being invisible to others." (Office Action, Dec. 13, 2007, p. 
15.) While the cited portion of Bunney does describe that a user may have a status of 
invisible, Bunney does not disclose changing the master status to offline if the first status 
update indicates the user is invisible. Bunney does not create or maintain a master status, 
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nor does it receive a status update. Bunney's invisible status merely prevents a user from 
being visible to other users' searches and from receiving other users' notifications. 
According to Bunney, if a user is invisible, other users will not know anything about the 
user, not even that the user is online. The first priority rule is not disclosed by Bunney. 

It is the Examiner's position that Aravamudan discloses the fourth and fifth of these 
priority rules. The Examiner points to Aravamudan's abstract as teaching "the use of 
instant messaging in conjunction with access to data and communication network channels 
and modes" and to Aravamudan at 9:45-67 and 10:1-51 as teaching "the use of the proxy 
always appearing to the buddy and real presence being advertised to other[s] who have 
identified the user as a buddy." {Id., p. 16.) The Examiner believes that one would be 
motivated to modify Bunney and Runyan in view of Aravamudan "because it would result 
in the most accurate presence for a user." {Id.) However, rather than a priority system 
executed by the server as in applicant's technology, Aravamudan describes a priority 
system that is selected by the user. The user may assign a priority to each buddy or group 
of buddies. In the exemplary embodiment described, the user may select among low, 
high, and highest priorities. These priorities determine to what status information other 
users have access and how other users may communicate with the user. Also unlike 
applicant's technology, Aravamudan's priority system does not reconcile differing user 
statuses associated with two or more clients. Instead, priorities are assigned to other 
users by the user, and such priorities do not relate to the other user's status (e.g., 
available, away, busy). Instead, the priorities determine how another user may interact 
with the user who assigned the priority. Unlike applicant's technology, Aravamudan does 
not teach or suggest a priority system executed by a server and, in particular, does not 
teach or suggest the particular priority rules as claimed. 
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e. Mundav fails to teach or suggest when one client 
indicates that the user is busy and another client 
indicates that the user is idle, setting the master status 
to indicate that the user is busy. 

Claim 30 recites "when the client presence status reported by one client indicates 
that the user is busy and by another client indicates that the user idle, setting the master 
presence status to indicate that the user is busy." That is, a user who is busy on one client 
but idle on another client will still be accurately reflected as busy. 

The Examiner acknowledges that Bunney and Runyan fail to teach this limitation. 
The Examiner points to Munday to cure this deficiency. (Office Action, Dec. 13, 2007, p. 
17-18.) It is the Examiner's position that Munday's abstract teaches "a communications 
system automatically diyerting calls when a user is not present," and that Munday at 4:51- 
67 and 5:1-18 teaches "the use of keeping the main status when a computer is determined 
idle." {Id., p. 18.) These portions of Munday describe a process for determining whether a 
user interaction with the computer system has occurred. If no user interaction has 
occurred within a predetermined period of time, a call divert process is initiated, diverting 
calls from a local telephone to a remote telephone. After the call divert process has been 
initiated, once the user interacts with the computer system again, call divert is removed. It 
is unclear what the Examiner is referring to by "the main status," and thus "keeping the 
main status when a computer is determined idle." {Id.) Indeed, it appears that Munday's 
"main status" is receiving calls at a local telephone as usual. This "main status" occurs 
when a user is interacting with the computer, not "when [the] computer is determined idle" 
as the Examiner has indicated. 

Moreover, Munday does not disclose or suggest "one client indicates that the user 
is busy and another client indicates that the user is idle." Munday discloses only one 
"client" - the user's computer system. When the user is interacting with the computer 
system, calls are received at the user's local telephone. When the user is not interacting 
with the computer system (i.e., the computer system is idle), calls are diverted to the user's 
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remote telephone. Munday offers no suggestion that "one client indicates that the user is 
busy and another client indicates that the user is idle" as recited. 

Furthermore, applicant can find nothing in Munday that discloses or suggests "a 
master status." As described above, applicant's master status is generated to represent 
the accurate overall status of a user who is online via multiple clients at the same time. 
Munday describes only one client - the user's computer system - with which the user may 
interact. Munday offers no suggestion that it evaluates a user's status on each of two or 
more clients to determine a master status. Moreover, Munday fails to disclose or suggest 
the particular condition for setting a master status to busy as recited by this claim, that is 
"when the client presence status reported by one client indicates that the user is busy and 
by another client indicates that the user idle." 

f. Aravamudan fails to teach or suggest when all but one 
client indicates that the client is offline, setting the 
master status to the status of the client that is currentiv 
online. 

Claim 31 recites "when the client presence status reported by all but one client 
indicates that the client is offline, setting the master presence status to the client presence 
status of the client through which the user is currently online." That is, a user who is online 
through only one client will be accurately reflected by the status associated with that client. 

The Examiner acknowledges that Bunney and Runyan fail to teach this limitation. 
The Examiner points to Aravamudan to cure this deficiency. (Office Action, Dec. 13, 2007, 
p. 18.) It is the Examiner's position that Aravamudan at 9:45-67 and 10:1-51 "teaches the 
use of the proxy always appearing available to the buddy and real presence being 
advertised to other[s] who have identified the user as a buddy." As described above, 
Aravamudan's user may assign a priority - such as low, high, or highest - to each buddy 
or group of buddies. The cited portions of Aravamudan describe that buddies assigned a 
low priority will always see a proxy associated with a user, but will not be able to discern 
the "real presence" of the user. Buddies that are assigned a high or highest priority will be 
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able to see the "real presence" of the user. However, Aravamudan offers no suggestion 
that its user may have a different "presence status" associated with each of multiple 
clients. Nor does Aravamudan disclose or suggest reconciling such different presence 
statuses to determine the "real presence" of the user. Moreover, Aravamudan fails to 
disclose or suggest the particular condition for setting the master presence status to the 
client presence status of the client through which the user is currently online as recited by 
this claim, that is "when the client presence status reported by all but one client indicates 
that the client is offline." 

3. Response to the Section 103(a) Rejection of Claims 1-4. 6-8. 10-14. 
16-22. 24-27. 29, and 32 Over Bunnev and Runvan 

Claims 1-4, 6-8, 10-14, 16-22, 24-27, 29, and 32 were rejected under 35 U.S.C. 
§ 103(a) over Bunney and Runyan. For the reasons described below, the Examiner has 
failed to establish that these claims are obvious over Bunney and Runyan. 

a. Claims 1-4 and 6-8 

Claims 1-4 and 6-8 recite "the electronic messaging user ... who is logged on via 
both the first client computer system and the second client computer system as an 
electronic messaging user." As discussed above in section 2.b, one would not be 
motivated to combine Runyan's suggestion that a user may be logged on to several clients 
with Bunney's system that allows a user to be logged on to only one address. 

These claims also recite "in response to receiving the first status update, the server 
evaluating at least the first status update, the first view status, and the second view status 
according to specified status rules to determine the master status of the electronic 
messaging user ...." As discussed above in section 2. a, neither Bunney nor Runyan 
teaches or suggests this feature. 
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Tliese claims also recite "reflecting an indication of the master status for the 
electronic messaging user ... to other electronic messaging users." As discussed above in 
section 2.c, neither Bunney nor Runyan teaches or suggests this feature. 

b. Claims 10-14 and 17-18 

Claims 10-14 and 17-18 recite "the electronic messaging user being logged on as 
an electronic messaging user ... through at least two clients at the same time." As 
discussed above in section 2.b, one would not be motivated to combine Runyan's 
suggestion that a user may be logged on to several clients with Bunney's system that 
allows a user to be logged on to only one address. 

These claims also recite: 

consolidating at the server the presence information for the electronic 
messaging user ... based on an evaluation of each view status such that the 
consolidated presence information is representative of a current status of the 
electronic messaging user even if some view statuses differ, wherein the 
consolidated presence information is maintained in a master view; 

receiving at the server a status update from one of the one or more clients; 
and 

updating in the master view at the server the consolidated presence 
information for the electronic messaging user ... based on an evaluation of 
the status update and each view status. 

As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. 

c. Claim 16 

Claim 16, which depends from claim 10, is patentable over Bunney and Runyan for 
the same reasons as claim 10. Claim 16 further recites "reflecting the updated presence 
information in the master view to the subscribers." As discussed above in section 2.c, 
neither Bunney nor Runyan teaches or suggests this feature. 
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d. Claims 19-22 and 24-26 

Claims 19-22 and 24-26 recite "the user being logged onto at least two clients at the 
same time to receive electronic messages." As discussed above in section 2.b, one would 
not be motivated to combine Runyan's suggestion that a user may be logged on to several 
clients with Bunney's system that allows a user to be logged on to only one address. 

These claims also recite: 

setting at the server the master status based on an evaluation of each client 
view status; and 

for each subsequent status change received from one of the multiple clients 
at the server, updating the master status in accordance with an evaluation of 
the subsequent status change and each client view status. 

As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. 

These claims also recite "the presence information reflected to the subscribers 
corresponds to the master status." As discussed above in section 2.c, neither Bunney nor 
Runyan teaches or suggests this feature. 

e. Claim 27 

Claim 27 recites "the user being logged onto at least two clients at the same time to 
receive electronic messages." As discussed above in section 2.b, one would not be 
motivated to combine Runyan's suggestion that a user may be logged on to several clients 
with Bunney's system that allows a user to be logged on to only one address. 

This claim also recites: 

consolidate at the server presence information for the user based on an 
evaluation of each view status such that the consolidated presence 
information is representative of a current status of the user; 

receive at the server a status update from one of the one or more clients; 
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update at the server the consolidated presence information for the user 
according to the status update. 

As discussed above in section 2. a, neither Bunney nor Runyan teaches or suggests this 
feature. 

This claim also recites "reflect at the server the updated consolidated presence 
information to the subscribers such that the appropriate presence information is provided 
to the subscribers even if some view statuses differ." As discussed above in section 2.c, 
neither Bunney nor Runyan teaches or suggests this feature. 

f. Claims 29 and 32 

Claims 29 and 32 recite "a user who is online via multiple clients at the same time." 
As discussed above in section 2.b, one would not be motivated to combine Runyan's 
suggestion that a user may be logged on to several clients with Bunney's system that 
allows a user to be logged on to only one address. 

These claims also recite "generating the master presence status representing a 
current presence status of the user based on the received client presence statuses 
reported by the multiple clients." As discussed above in section 2.a, neither Bunney nor 
Runyan teaches or suggests this feature. 

4. Response to the Section 103(a) Reiection of Claims 9. 15. 23. and 28 
Over Bunnev. Runyan. Aravamudan. and Mundav 

Claims 9, 15, 23, and 28 were rejected under 35 U.S.C. § 103(a) over Bunney, 
Runyan, Aravamudan, and Munday. For the reasons described below, the Examiner has 
failed to establish that these claims are obvious over Bunney, Runyan, Aravamudan, and 
Munday. 
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a. Claim 9 

Claim 9, which depends from claim 1 , is patentable over Bunney and Runyan for the 
same reasons as claim 1 . Claim 9 further recites updating the master status according to 
a detailed priority system. Claim 9 recites: 

... changing the master status according to a priority system further 
comprises: 

changing the master status to offline if the first status update indicates 
the electronic messaging user ... is invisible; 

refraining from changing the master status if the first status update 
indicates electronic messaging user ... is offline; 
refraining from changing the master status if the first status update 
indicates the electronic messaging user ... is idle; 

changing the master status to offline if the first status update indicates 
the electronic messaging user ... is offline and one or more remaining 
view statuses associated with the messaging client, including the 
second view status, indicate the electronic messaging user ... is 
offline; and 

changing the master status to idle if the first status update indicates 
the electronic messaging user ... is idle and one or more remaining 
view statuses associated with the messaging client, including the 
second view status, indicate the electronic messaging user ... is idle 
or offline. 

As discussed above in section 2.d, Bunney, Runyan, Aravamudan, and Munday each fail 
to teach or suggest this feature. 

b. Claim 15 

Claim 15, which depends from claim 14, is patentable over Bunney and Runyan for 
the same reasons as claim 14. Claim 15 further recites updating the master status 
according to a detailed priority system. Claim 15 recites: 

... changing the presence information according to a priority system further 
comprises at least one of: 

changing the presence information to offline if the status update 

indicates the electronic messaging user is invisible; 
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refraining from changing the presence information if the status update 
indicates the electronic messaging user is offline; 

refraining from changing the presence information if the status update 
indicates the electronic messaging user is idle; 

changing the presence information to offline if the status update 
indicates the electronic messaging user is offline and the remaining 
view statuses indicate the electronic messaging user is offline; 

changing the presence information to idle if the status update 
[indicates] the electronic messaging user is idle and the remaining 
view statuses indicate the electronic messaging user is idle or offline; 
and 

changing the presence information to match the status update. 

As discussed above in section 2.d, Bunney, Runyan, Aravamudan, and Munday each fail 
to teach or suggest this feature. 



c. Claim 23 

Claim 23, which depends from claim 19, is patentable over Bunney and Runyan for 
the same reasons as claim 19. Claim 23 further recites updating the master status 
according to a detailed priority system. Claim 23 recites: 

... changing the master status according to a priority system further 
comprises at least one of: 

changing the master status to offline if the subsequent status update 
indicates the user is invisible; 

refraining from changing the master status if the status update 
indicates the user is offline; 

refraining from changing the master status if the subsequent status 
update indicates the user is idle; 

changing the master status to offline if the subsequent status update 
indicates the user is offline and the remaining client view statuses 
indicate the user is offline; 

changing the master status to idle if the subsequent status update 
indicates the user is idle and the remaining client view statuses 
indicate the user is idle or offline; and 

changing the master status to match the subsequent status update. 
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As discussed above in section 2.d, Bunney, Runyan, Aravamudan, and IVIunday each fail 
to teach or suggest this feature. 



Claim 28, which depends from claim 27, is patentable over Bunney and Runyan for 
the same reasons as claim 27. Claim 28 further recites updating the master status 
according to a detailed priority system. Claim 28 recites: 

... updating the presence information further comprises: 



changing the presence information to offline if the status update 
indicates the user is invisible; 

refraining from changing the presence information if the status update 
indicates the user is offline; 

refraining from changing the presence information if the status update 
indicates the user is idle; 

changing the presence information to offline if the status update 
indicates the user is offline and the remaining view statuses indicate 
the status of the user is offline; 

changing the presence information to idle if the status update indicates 
the user is idle and the remaining view statuses indicate the user is 
idle or offline; and 

changing the presence information to match the status update. 



As discussed above in section 2.d, Bunney, Runyan, Aravamudan, and Munday each fail 
to teach or suggest this feature. 

5. Response to the Section 103(a) Rejection of Claim 30 Over Bunnev. 
Runyan. and Munday 

Claim 30 was rejected under 35 U.S.C. § 103(a) over Bunney, Runyan, and 
Munday. For the reasons described below, the Examiner has failed to establish that this 
claim is obvious over Bunney, Runyan, and Munday. 



d. 



Claim 28 



a. 



Claim 30 
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Claim 30, which depends from claim 29, is patentable over Bunney and Runyan for 
the same reasons as claim 29. Claim 30 further recites "when the client presence status 
reported by one client indicates that the user is busy and by another client indicates that 
the user idle, setting the master presence status to indicate that the user is busy." As 
discussed above in section 2.e, Bunney, Runyan, and Munday each fail to teach or 
suggest this feature. 

6. Response to the Section 103(a) Reiection of Claim 31 Over Bunnev. 
Runyan. and Aravamudan 

Claim 31 was rejected under 35 U.S.C. § 103(a) over Bunney, Runyan, and 
Aravamudan. For the reasons described below, the Examiner has failed to establish that 
this claim is obvious over Bunney, Runyan, and Aravamudan. 

a. Claim 31 

Claim 31, which depends from claim 29, is patentable over Bunney and Runyan for 
the same reasons as claim 29. Claim 31 further recites "when the client presence status 
reported by all but one client indicates that the client is offline, setting the master presence 
status to the client presence status of the client through which the user is currently online." 
As discussed above in section 2.f, Bunney, Runyan, and Aravamudan each fail to teach or 
suggest this feature. 

Conclusion 

Based on the above amendments and remarks, applicant respectfully requests 
reconsideration of this application and its early allowance. If the Examiner has any 
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questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-8548. 



Dated: f([(h^cJ(f, \ 7DO^ Respectfully submitted, 

Maurice J. Pirio 

Registration No.: 33,273 
PERKINS COIE LLP 
P.O. 60x1247 

Seattle, Washington 9811 1 -1 247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorneys for Applicants 
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